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Introduction 



Les Design Patterns (en frangais Patrons de conception, IVIodeles de conception ou 
encore IVIotifs de conception sent un recueil de bonnes pratiques de conception pour 
un certain nombre de problemes recurrents en programmation orientee objet. 

Les designs patterns decrivent des organisations pratiques de classes objets. Ces 
organisations resultent souvent d'une conception empirique, le concepteur objet 
tente de faciliter la reutilisation et la maintenance du code. On peut done concevoir 
un modele d'application comme une forme d'organisation transposable a plusieurs 
applications. Ces systemes peuvent apparaitre complexes aux debutants voire 
inutiles, il est pourtant tres important d'en connaitre plusieurs et de les appliquer 
systematiquement (dans les cas reconnus comme pouvant evoluer). 

Les patrons de conception decrivent des solutions standard pour repondre a des 
problemes d'architecture et de conception des logiciels. A la difference d'un 
algorithme qui s'attache a decrire d'une maniere formelle comment resoudre un 
probleme particulier, les patrons de conception decrivent des precedes de 
conception generaux. On peut considerer un patron de conception comme une 
formalisation de bonnes pratiques. 

On peut done considerer les patrons de conception comme un outil de capitalisation 
de I'experience applique a la conception logicielle. 

Le but general des patrons de conception est de minimiser les interactions qu'il peut 
y avoir entre les differentes classes (ou modules, plus generalement) d'un meme 
programme. L'avantage de ces patrons est de diminuer le temps necessaire au 
developpement d'un logiciel et d'augmenter la qualite du resultat, notamment en 
appliquant des solutions deja existantes a des problemes courants de conception. 



(Description du projet 



Le projet consiste a analyser et concevoir et implanter deux patrons de conceptions 
observateur, la fabrique abstraite en les appliquant sur un jeux de des. 

Le jeu consiste a lancer 10 fois 2 des. Si le total des 2 des fait 7, il marque 10 points 
a son score, sinon 1! n'en marque rien. En fin de partie, son score est inscrit dans le 
tableau des 'high scores'. 



1-L 'anaCyse des Besoins (definition desfonctionnaCites attendues) 

1-1 Diagramme de cas d'utilisation 




View High Score 



Description du cas Play 



Acteur : Player 

Description : Le joueur lance 10 fois les des, a chaque fois que le total des 

deux des fait 7, son score augmente de 10 points. 



Description du cas View High Score : 

• Acteur: Player 

• Description: Le joueur consulte en lecture seul les high score 



1-2 diagramme d'activite 

Sa construction permet de decrire I'organisation generale des traitements et permet 
de dialoguer avec les 'clients'. 
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II doit exister une certaine coherence entre ces diagrammes. On peut verifier que 
tous les cas se retrouvent quelque part dans le diagramme d'activites. 



2. L'analyse (definition des classes du domaine et de 
leur dynamique) 



2-1 Diagramme de collaboration 

Ce diagramme permet de visualiser des objets, leurs relations et rordonnancement 
des appels de messages. 




game : Dice 
Game 



Memo : Player 



2-2 Diagramme de classes 



On complete les classes et on represente leurs associations statiques et 
dynamiques; on definit les attributs des classes et les cardinalites des associations. 
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2-3 Diagramme de sequences 

lis modelisent la dynamique (comme diagrammes de collaboration) en se focalisant 
sur renchainement des messages. 
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d2 : Die 
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2-4 Diagramme d'etat 

II a pour objet de determiner les etats et transitions d'etat d'un objet. lei le diagramme 
d'etats d'une partie (diceGame). 
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3. La conception 



3-1 Architecture 

On fait le choix d'une architecture en couches comportant tres classiquement 3 
couches. 
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Fichier ou BDD 



3-2 Conception du niveau applicatif 
3-2-1 le pattern singleton 

Assure qu'une classe a una instance unique qu'elle garde dans une variable de 
classe (static uniquelnstance) et donne un point d'acces depuis la classe a cette 
instance (methode de classe static InstanceQ ou getlnstanceQ). 
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Sont egalement ajoutees des methodes pour sauvegarder les high score (load, save) 
et pour afficher les des et joueurs (display). 



3-2-2 le pattern observer 

Un objet (le sujet) est lie a plusieurs objets (les observateurs ou observers) pas 
necessairement connus a la creation du programme. Toute modification est 
automatiquement repercutee (notifiee) a tous les observateurs. 

lei, les des et les joueurs sont les sujets (classe Observable) et les vues sur les des 
et sur les joueurs sont les observateurs (interface Observer). 
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3-2-3 Diagramme de classe 



RolForm 
(from Ul) 



^roll_action() 

*cancel_action() 

*RollForm() 



Observable 
(from util) 




"^+the P la ye rV I evy 9 r V I ew 
^^- (from Ul) 



1 



^PlayerVlewQ 
*update() 



7 T 



^ 



"^^ «lnterface» 
^ Observer 



''from util) 
0..* 



Player 



^ 



*rollO 
*DieO 
^displayO 
*setValueO 



%-name : String 
^score : int = 0; 



*Player() 
^displayO 



3-2-4 Diagramme de sequence 
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3:start_action() 
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8: return component 
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3-3 Le niveau persistance Persist 



II contient les classes techniques de persistance. L'objectif est d'assurer 
I'independance Core/Persist afin de pouvoir utiliser plusieurs types de persistance. 
Par exemple, la serialisation (persistance d'objets lies dans un fichier) et I'utilisation 
d'une base de donnees relationnelle (via JDBC). Pour cela, on fait appel au pattern 
Factory. Ce pattern sert quand une classe peut creer des objets (ProduitConcret) de 
differentes classes. Une interface unique (Fabrication) est implantee par differentes 
classes concretes pour chaque type d'objet a creer (FabricationConcrete). La classe 
qui veut creer les objets peut ne travailler qu'avec les interfaces. 
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3-4 Conception du niveau interface utilisateur 

II faut definir les fenetres graphiques ('forms') contenant eventuellement les 
panneaux vues. Toutes les forms heritent de la classe awt Frame. 

Fenetre de demarrage 
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Le bouton jouer pour commencer une partie de jeu. 

Le bouton meilleurs scores pour voir une liste des meilleurs scores obtenus. 

Le bouton quitter pour quitter I'application. 

Fenetre d'identification 
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Score : affiche le score obtenu 

N° d'essais : nombre d'essai jouer, il s'arrete a 10. 

De 1 : le resultat de premier de. 

De 2 : le resultat de deuxieme de. 



Condusion 



L'analyse des besoins a utilise 

■ cas d'utilisations + descriptions, 

■ diagramme d 'activites, 

■ prototypage de I'interface utilisateur. 

L'analyse a utilise 

■ pour la dynamique : les diagrammes de collaborations, sequences, etats, 

■ pour la statique : les diagrammes de classes. 

La conception a utilise : 

■ le pattern architectural Layer 

■ les diagrammes de paquetages, de composants, de deploiement, 

■ les design patterns Singleton, Observer, Factory, 

■ des classes techniques pour la persistance et I'interface utilisateur. 

La realisation a utilise les outils de generation et de retro conception. II est 
indispensable de mettre a jour la documentation d'analyse et de conception. Les 
tests ont utilise les cas d'utilisation (couverture des fonctionnalites) et le diagramme 
d'activite (conformite). Bien entendu sur des grosses applications les demarches de 
test sent plus complexes (integration, non regression, ...). 

UML permet d'avoir plusieurs points de vue a chaque etape et de reflechir en termes 
de couverture et de coherence. Le travail est facilite avec un atelier UML. 

UML permet de documenter les choix d'analyse et de conception. Grace au 
processus de developpement maitrise, le produit est conforme a ce qui etait prevu au 
depart. Grace aux patterns, le produit est evolutif (on peut facilement modifier 
I'interface ou la persistance). Grace a Java, le produit est portable (systeme, SGBD). 



